Microsoft Entra ID
Multi-Factor Authentication
Conditional Access
Identity Protection
Break-glass accounts
Day 1
MFA methods & SSPR
Day 2
Conditional Access fundamentals
Day 3
Named locations & risk policies
Day 4
Break-glass, What If & CA testing
Day 5
Review & assessment
Week 2 builds the identity security layer that sits between the user accounts created in Week 1 and everything that follows. MFA and Conditional Access are the two most impactful controls any M365 administrator can deploy — studies consistently show MFA alone blocks over 99% of automated credential attacks. By Friday, every Lakeview Logistics sign-in requires MFA, is evaluated against location and risk conditions, and is governed by a set of CA policies that will remain active for the rest of the course.
The four CA policies built this week
CA001
Require MFA for all users
All cloud apps · All locations
Excludes break-glass account
CA002
Block legacy authentication
All cloud apps · Exchange ActiveSync + Other clients
No MFA possible on legacy protocols
CA003
Block sign-ins from high-risk locations
Named locations configured
Block access from untrusted countries
CA004
Require MFA for admin roles
Targets Global Admin, Security Admin etc.
Stricter auth strength (phishing-resistant)
All CA policies start in Report-only mode. During the lab, policies are configured and saved in Report-only — they evaluate sign-ins and log what would have happened, but do not actually block or enforce yet. Bonus B on Day 2 switches CA001 to On. This is the production best practice: simulate before enforcing to avoid accidental lockouts. By Week 6, all four policies will be enforcing.
Daily breakdown
Day 1
Lecture: MFA architecture, authentication methods, SSPR
Lab 2-A: Enable MFA per-user for all Lakeview Logistics accounts → configure authentication methods policy (Microsoft Authenticator, FIDO2, SMS) → register MFA for the admin account → enable and configure SSPR
Day 2
Lecture: Conditional Access architecture — conditions, controls, policy evaluation order
Lab 2-B: Create CA001 (require MFA — all users, all apps, Report-only) → create CA002 (block legacy auth) → review sign-in logs in Report-only → Bonus B: switch CA001 to On
Day 3
Lecture: Named locations, IP ranges, country-based restrictions, Entra ID Identity Protection risk levels
Lab 2-C: Configure named locations (trusted office IP range) → create CA003 (block high-risk countries) → review Identity Protection risk events → configure sign-in risk policy
Day 4
Lecture: Break-glass accounts, authentication strength, CA What If tool
Lab 2-D: Create emergency break-glass account → configure CA004 (require MFA for admins, auth strength: phishing-resistant) → use What If tool to simulate sign-in scenarios → verify break-glass account bypasses CA001
Day 5
Review: full CA policy stack, policy interaction, sign-in log reading
Assessment: sign-in log investigation + CA policy gap analysis + implement one hardening improvement
Key concepts introduced this week
| Concept | What it is | Why it matters for the rest of the course |
| Conditional Access | Policy engine that evaluates every sign-in against conditions (user, location, device, risk) and applies grant or block controls | CA policies created this week remain active and gain additional conditions in Weeks 6 (device compliance) and 7 (Defender risk level). All subsequent weeks assume CA is running. |
| Authentication methods policy | Controls which MFA methods (Authenticator app, FIDO2 key, SMS, voice) are available to which users | The method registered here determines whether phishing-resistant MFA (CA004) can be satisfied. FIDO2 and certificate-based auth are the only phishing-resistant options. |
| Named locations | IP ranges or country/region lists assigned a trusted or untrusted designation in Entra ID | CA003 uses named locations to block sign-ins from untrusted countries. Lab environments may need the college IP added to the trusted range so lab sign-ins aren't blocked. |
| Report-only mode | A CA policy state that evaluates and logs without enforcing — shows what would have happened | All new CA policies should start in Report-only. The sign-in logs show the Report-only result alongside the enforced result. Week 6 switches remaining policies to On. |
| Break-glass account | An emergency Global Admin account excluded from all CA policies, stored with credentials in a sealed physical location | Without a break-glass account, a misconfigured CA policy that locks out all admins is unrecoverable without Microsoft Support. CA004 is configured to exclude the break-glass account. |
| Identity Protection risk | Entra ID's ML-based risk scoring for users (user risk) and sign-in events (sign-in risk) — Low, Medium, High | Risk levels feed into CA policy conditions (sign-in risk = High → require MFA or block). Week 7's Defender for Endpoint also contributes device risk signals to the same framework. |
| Legacy authentication | Older authentication protocols (Basic Auth over SMTP/POP3/IMAP, Exchange ActiveSync pre-modern auth) that cannot perform MFA | CA002 blocks all legacy auth permanently. Any application using legacy auth (old mail clients, on-prem connectors) must be updated before CA002 is enforced. This is one of the most impactful single controls. |
CA policy configuration summary — built by end of Week 2
| Policy | Users | Apps | Conditions | Grant / Block | State at week end |
| CA001 — Require MFA all users | All users (excl. break-glass) | All cloud apps | None (applies everywhere) | Require MFA | On (Bonus B) or Report-only |
| CA002 — Block legacy auth | All users | All cloud apps | Client apps: Exchange ActiveSync + Other clients | Block access | On |
| CA003 — Block high-risk locations | All users | All cloud apps | Locations: exclude named trusted locations | Block access | Report-only |
| CA004 — Admin MFA (phishing-resistant) | Admin roles (Global Admin, Security Admin etc.) | All cloud apps | None additional | Require auth strength: phishing-resistant MFA | Report-only |
Week 2 connections to the rest of the course
| Week 2 element | Connected to | How |
| CA001 — Require MFA (all users) | Week 6, Lab 6-B | CA001 gains a second grant control: Require device to be marked as compliant. From that point, users must have both MFA and a compliant Intune-enrolled device to access M365. |
| CA001 — Require MFA (all users) | Week 7, Lab 7-B | CA001 gains a third signal: Defender for Endpoint device risk level. A device with active malware is marked non-compliant and blocked automatically. |
| Break-glass account | All weeks | The break-glass account is the recovery path if any CA policy misconfiguration locks out all admins. It is excluded from CA001, CA002, CA003, and CA004. |
| Authentication methods policy | Week 2 CA004, Week 8 capstone | Phishing-resistant MFA (FIDO2) configured this week is required by CA004 for admin sign-ins. The capstone assessment asks students to audit which users have registered phishing-resistant methods. |
| Identity Protection risk policies | Week 7 — Defender signals | Entra ID Identity Protection and Defender for Endpoint both contribute risk signals to the same framework. Week 7 connects device-level threat intelligence to the sign-in risk score. |
| Named locations | Week 8 — audit log investigation | The IP address in an audit event is compared against named locations to determine whether a sign-in came from a trusted or untrusted location — key context for the Week 8 incident timeline. |
Portals used this week
| Portal | URL | Used for |
| Microsoft Entra admin centre | entra.microsoft.com | All Conditional Access, MFA, named locations, Identity Protection, authentication methods — primary portal for Week 2 |
| Microsoft 365 admin centre | admin.microsoft.com | Per-user MFA settings (legacy), licence assignments, user management |
| Entra ID sign-in logs | entra.microsoft.com → Monitoring → Sign-in logs | Reviewing CA policy evaluation results in Report-only mode, investigating sign-in failures |
Key design decisions for Week 2
Report-only first, enforce second. All CA policies are created in Report-only mode. This lets students see the effect of the policy in the sign-in logs before it actively blocks anyone. Switching to On is covered in Bonus B (CA001) and is the deliberate last step — not the first. In production, Microsoft recommends at minimum a 48-hour Report-only monitoring period before enforcing any new CA policy.
CA002 (block legacy auth) goes On immediately. Unlike the other policies, CA002 can be enforced on Day 2 because it blocks authentication protocols that should never be in use in a modern M365 tenant. If any application breaks after CA002 is enforced, that application is using legacy auth and needs to be updated — not a reason to revert the policy.
The break-glass account exclusion is non-negotiable. CA001 must exclude the break-glass account using the Users exclusion, not a group exclusion. If the break-glass account is in a group that is later modified, it might accidentally fall back under CA scope. Individual account exclusion is the only safe approach.
Students must register MFA before CA001 is switched to On. If CA001 enforces MFA and a user has not registered any MFA method, they are locked out immediately with no self-service recovery path. All 10 Lakeview Logistics accounts should have MFA registered (at minimum the Authenticator app) before Bonus B is attempted.
Learning outcomes — by end of Week 2, students can…
Configure MFA methodsEnable and scope authentication methods including Microsoft Authenticator and FIDO2 security keys
Build CA policiesCreate Conditional Access policies with user, app, condition, and grant/block controls
Read sign-in logsInterpret Entra ID sign-in logs including Report-only CA results and failure reasons
Configure named locationsDefine trusted IP ranges and use them as conditions in CA policies
Use the What If toolSimulate sign-in scenarios to predict CA policy outcomes before enforcement
Manage break-glass accountsCreate and exclude an emergency admin account from all CA policies
Explain Identity ProtectionDescribe user risk and sign-in risk scoring and how they connect to CA policy conditions